Raster images, or bitmaps, are well known, and have long been used for the display of computer graphics. A bitmap is a pixel-by-pixel map of how an image should be rendered on a computer or video display or printout, defining the location, color, intensity, etc. of each pixel. Although numerous schemes for compressing bitmaps have been employed, including the JPEG (Joint Photographic Experts Group), GIF (Graphics Interchange Format), and PNG (Portable Network Graphics) standards, in general raster images suffer from the shortcoming that it is impractical to encode raster images with large amounts of information regarding the data attributes of raster image data. Thus, raster images are usually static and do not provide interactive functionality such as allowing a user to click on a certain point in an image to change how the image is displayed, or to obtain more information about a point or points in the image. However, raster images have certain advantages, including the facts that they are simply organized, easy for programmers to understand, and generally efficient for microprocessors to handle.
Vector graphics are similarly well known, and have long been used to pictorially present image data on computer systems. A vector graphic is essentially a set of instructions for drawing geometric shapes that are used to represent images on a computer or video display or printout. Where a bitmap file includes a bit or, more likely, a set of bits, describing each pixel to be included in an image, a vector graphic file is simply a list of geometric shapes along with attributes indicating how the shape is to be rendered. For example, a vector graphic file might list a rectangle, the attributes of which would include dimensions (length and width), color, fill pattern, location, orientation, etc. As with bitmaps, different standards for vector graphics files exist. One such standard is the SVG (Scalable Vector Graphics) Specification 1.1. (W3C Recommendation 14 Jan. 2003), promulgated by the World Wide Web Consortium of Cambridge, Mass., fully incorporated herein in its entirety by reference. Vector graphics files have the advantages of consuming smaller amounts of memory than bitmap files, and often can render images with greater precision, particularly at higher resolutions. However, vector graphics files sometimes consume large amounts of processing overhead to render certain images, such as images containing many complex polygons.
Accordingly, raster images are advantageous for presentation of complex static images where data is unlikely to need refreshing. Vector graphics, on the other hand, are desirable in situations requiring numerous attributes to be associated with image data, and in which flexibility in the display of an image is required. It would be desirable to be able to obtain the advantages of raster images and vector graphics, while minimizing the disadvantages of each kind of format.
Graphics data, whether rendered according to a bitmap or a vector graphics file, is very useful in many reporting applications. In most, if not all, applications users find it extremely useful to obtain a visual representation of data apart from words and numbers in a table. Thus, applications that query relational databases, computer spreadsheets, and even the World Wide Web, often represent data in some sort of graphical format in addition to, or in lieu of, presenting data in a strictly alpha-numeric format. To take a common example, relational databases known as data warehouses are designed specifically to support efficient construction of reports. Such databases are also often referred to as OLAP (On-line Analytical Processing) databases, indicating that they are designed to support analysis and review of information in the aggregate, as opposed to conventional OLTP (On-line Transactional Processing) databases, which are designed to support efficient storage and retrieval of information about individual events, e.g., transactions. OLAP databases are often constructed as part of DSS (decision support system) applications, also sometimes known as business intelligence applications. DSS applications are designed to allow users to quickly navigate through data by viewing data at different levels of aggregation. Such navigation is known as “drilling.”
One way to navigate through OLAP data is by viewing the data aggregated by different quantities of time; the data stored in OLAP databases almost always has a time attribute. To take a common example, most businesses aggregate sales transactions to report sales figures on a monthly level. Monthly sales figures are generally aggregated on a quarterly basis, and quarterly figures are generally aggregated on an annual basis. Thus, a user viewing a report showing sales figures on an annual basis might wish to obtain a more detailed view of sales trends, and therefore might do what is called “drill down” from the annual level to the quarterly level.
Besides time, another attribute that is very commonly associated with data in OLAP databases is location. In fact, roughly eighty percent of the data presently contained in OLAP databases has a geographical component. For example, a national retail organization may aggregate its data according to different geographic areas, e.g., telephone codes, postal codes, city, state, province, county, region, etc. Thus, a user viewing sales data aggregated at the national level may be provided with the ability to drill down to view data aggregated according to region, state, city, zip code, etc.
Another common feature of DSS applications is to provide charts and graphs representing reported data. Such functionality has been known almost since the inception of graphical user interfaces (GUIs). Certain data lends itself to particular graphical representations. For example, an executive looking at sales figures aggregated according to month may be interested in sales trends, and therefore presenting the data in a line graph format may be appropriate. Similarly, the same executive looking at sales figures aggregated according to region is likely interested in being able to easily discern which regions are the best and worst performers. The executive is likely also interested in being able to drill down into different regions, to determine how cities or states within each region are contributing to the region's overall performance—i.e., what areas have performance problems and/or what areas are responsible for good performance. Accordingly, it is known to display report data in the context of map images to facilitate geography-based analysis of that data.
Unfortunately, the components for displaying graphics, such as mapping components, suffer from a number of shortcomings in present reporting applications. Generally, such components are proprietary, meaning that they are designed to retrieve and render data that has been stored in the proprietary database of a particular software vendor. Accordingly, one such shortcoming stems from the fact that, in order to support image-based reporting, present applications require data to be added to a database that supports the specific imaging component, such as a mapping component, used by the reporting application. Similarly, statistical reporting applications require that data to be reported graphically must be stored in a proprietary application format. Accordingly, current reporting databases must undergo expensive and time-consuming customizations in order to support image-based reporting, and do not have the flexibility to be used with different, or non-proprietary, image servers or image databases.
Further, because present reporting applications display report data and image data based on the same data source, known reporting applications generally require that, when either report or image data is updated or refreshed, that both be updated or refreshed. Accordingly, present reporting applications limit the ability of users to view refreshed data. Moreover, when users of present reporting applications are able to view refreshed data, this functionality is inefficiently achieved with unnecessary processing overhead.
For example, the user of an OLAP reporting application might request a report showing an organization's total sales by state, the report to be presented as a map image. Present applications would formulate a single query to be sent to the OLAP server, which would in turn retrieve the requested report data from the OLAP database. Presently, it is a requirement for the OLAP database and/or OLAP server to provide both the report data (e.g., sales figures) and image data (e.g., map image) to be presented to the user. Once the afore-mentioned data is obtained, the OLAP server combines it into a single data structure. This data structure is then downloaded to the client, which uses it to present the requested report, as a map image, to the user. Disadvantageously, if the user wishes to have the report data refreshed, or wishes to make any change to the parameters of the report (e.g., show expense figures rather than sales figures, or focus on a different portion of a map), it is necessary to generate a new query, and carry out the process described above to create a new data structure incorporating both report data and image data for download to, and display by, the client.
Accordingly, it would be desirable to be able to create a reporting application in which existing, unrelated databases of both image and report data could be used together. It would further be desirable if image and report data from different databases could be displayed together, and refreshed independently of one another. Achieving such goals would enable the creation of flexible, efficient, highly functional reporting applications that have heretofore not been possible.